✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Code LGTM but I believe we have a stale playwright test now.

Thanks for the work on cross-node highlighting — the searchMatches() approach that handles text spanning decorated elements is a real improvement over the per-text-node regex matching.

So I am looking into this more, but the failing test is not stale, it just shows that this PR brings a regression compare to what I have tried to do in previous improvement. Here is my analysis for now

These tests were added in #14053 and cover specific edge cases in how search interacts with Bootstrap tabsets. They pass on current main (https://github.com/quarto-dev/quarto-cli/actions/runs/22241123723, after #14053 merged).

What the tests cover

The test fixture has multiple tabsets with search terms placed strategically to exercise different scenarios. The two failing tests are:

1. "Search keeps active tab when it already has a match"

When a search term (gamma-both-tabs) exists in both the R tab (active by default) and the Python tab, the expected behavior is to leave the R tab active — it already shows a match, so switching tabs would be disruptive. The previous activateTabsWithMatches() grouped marks by their parent .tab-content container and checked whether the active pane already had a match before deciding to switch. openAllTabsetsContainingEl() doesn't have this check — it activates every .tab-pane ancestor of every match node, so the last one processed wins and the mark in the other tab becomes hidden.

2. "Search activation overrides localStorage tab preference" (line 79)

When the user has a stored tab preference in localStorage (e.g., "R" for grouped language tabs) but the search term (python-only-content) only matches in the Python tab, search should override the stored preference to show the match. This depends on event timing: tabsets.js registers a pageshowhandler that readsquarto-persistent-tabsets-datafromlocalStorageand callstoggleAll()to restore previously-selected tabs. The previous code in #14053 handled this by registering tab activation as apageshowlistener duringDOMContentLoaded— listener ordering guarantees it runs aftertabsets.jsrestores stored state, so search activation wins. This PR runs tab activation synchronously during highlight() inDOMContentLoaded, so tabsets.js's pageshowhandler fires afterward and overwrites the search-driven tab state with thelocalStorage` preference.

What passes

The other 4 tests pass, which means the core mechanics work: activating an inactive tab for a match, nested tabset activation, not touching tabs when the match is outside tabs, and scrolling to the first match.

Suggestion

The cross-node searchMatches() / markMatches() approach is the right direction — the old per-text-node regex couldn't handle matches spanning decorated elements. The tab activation logic just needs to be brought forward. Specifically:

1. Before activating a tab, check whether the currently active pane in that tabset already contains a mark. If so, skip it.
2. Move tab activation to a pageshow listener (registered during DOMContentLoaded) so it runs after tabsets.js restores localStorage state.

I haven't verified locally whether there are other behavioral differences beyond what the tests catch (e.g., how the setTimeout scroll interacts with tab transitions vs the previous requestAnimationFrame approach), but these two are the confirmed regressions from CI.

Happy to discuss it. The demo website is there to show current behavior: https://cderv.github.io/quarto-search-highlight-demo/